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PREFACE 

This  thesis  describes  Item  Analysis,  a  program  that  analyzes 
a  user's  description  of  a  network  and  converts  it  into  a  structure  that 
is  suitable  for  analysis.   This  program  is  contained  in  the  graphics- 
oriented  simulation  and  modeling  system  developed  at  the  University  of 
Illinois.   This  report  also  contains  documentation  of  the  program  which 
may  not  be  of  interest  to  the  reader  who  only  needs  a  broad  description 
of  the  function  of  Item  Analysis.   Such  readers  are  encouraged  to  cover 
only  the  first  section  under  each  major  heading. 
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1 .   INTRODUCTION 

Item  Analysis  is  a  part  of  the  general  simulation  and  modeling 
system  developed  at  the  University  of  Illinois.   The  total  system  allows 
a  user,  through  interactive  graphics,  to  define  a  model  for  a  proposed  or 
existing  system.   The  model  consists  of  a  network  of  elements  and  its 
corresponding  equations.   Each  element  has  terminals  which  can  pass 
variables  (e.g.,  voltage,  current,  pressure)  to  other  elements.   In  a 
network,  terminals  are  connected  together  at  nodes.   In  a  recursive 
manner,  elements  can  be  networks  of  other  elements.   For  example,  current 
sources  and  diodes  could  be  defined  as  elements .   The  equivalent  circuit 
for  a  transistor  could  be  constructed  as  a  network  of  current  sources 
and  diodes.   Then  this  "transistor"  could  be  used  in  another  network 
(which  might  also  contain  diodes  and  current  sources).   User  element  and 
network  definitions  are  kept  in  a  file  and  can  be  used  or  modified  at 
any  time.   It  is  possible  for  a  network  to  be  solved  for  "steady  state 
conditions  (all  derivatives  zero),  dynamic  behavior  (numerical  integra- 
tion), or  small  perturbation  response  (eigenvalues  and  eigenvectors  of  the 
Jacobian  of  the  differential  equations)"  (see  [l],  [2]). 

When  the  user  is  ready  to  have  a  network  analyzed,  a  call  is 
made  to  Item  Analysis .   The  data  structures  that  have  been  created  in 
the  PDP-8  to  represent  the  network  are  sent  to  the  IBM  360  and  through 
the  GRASS  supervisory  system  (see  [3]).   Item  Analysis  works  upwards  from 
the  basic  (not  decomposable)  elements  to  the  entire  network  transforming 
the  structure  into  one  suitable  for  use  by  Global  Analysis  (see 
Figure  l)  which  works  in  the  opposite  direction.   Variable  name  tables 
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axe  created  for  each  element  which  is  referred  to  in  the  equation  trees. 
All  of  the  equations  are  parsed  and  placed  in  coded  form  in  binary  trees. 
Item  Analysis  detects  syntax  errors  in  equations  and  gross  errors  in 
element  definition  and  informs  the  user.   Tables  are  created  in  the  output 
which  can  later  be  used  in  communicating  results  or  errors  detected  in 
equations  that  have  been  modified  at  almost  every  level  in  the  system. 
Each  element  in  a  network  must  be  put  through  Item  Analysis  before  the 
complete  network  can  be  analyzed.   Once  they  have  been,  however,  the 
elements  need  never  be  put  through  Item  Analysis  again  if  their  definition 
remains  unchanged.   Thus,  a  resistor  can  be  put  through  Item  Analysis 
once  and  then  used  in  as  many  networks  as  desired  without  "re-Itemizing" 
the  resistor  for  every  network.   When  each  element  and  the  network  has 
been  through  Item  Analysis ,  control  is  then  passed  to  Global  Analysis 
which  leads  to  the  remainder  of  the  simulation  system. 


2.   INPUT/OUTPUT  COMMUNICATIONS 


2.1  Remote  Monitor 


Item  Analysis  operates  in  the  360  under  a  two  level  monitor 
(see  Figure  2).   The  top  level,  G80PERAT,  handles  the  actual  data 
transmission  over  the  2701  data  link  between  the  PDP-8  and  the  360  and 
can  attach  or  detach  the  second  level  upon  command.   Thus,  G80PERAT  is 
the  only  program  that  must  be  running  when  a  user  attempts  to  commun- 
icate with  the  360.   The  second  level  monitor,  SPACT,  handles  the 
attaching  or  detaching  of  user  program  modules  (e.g.,  Item  Analysis). 
The  S8  macros  (section  2.2)  are  used  to  communicate  between  the  user 
and  Item  Analysis  through  SPACT  and  G80PERAT.   Commands  and  input 
structures  are  sent  from  the  PDP-8  and  error  messages  are  sent  from 
Item  Analysis  to  the  user  in  this  manner.   Since  SPACT  and  G80PERAT 
do  not  examine  or  modify  the  records  they  transmit,  Item  Analysis  must 
ensure  that  each  record  that  is  sent  or  received  is  in  the  proper  format, 

Output  data  structures  are  handled  by  the  filing  system 
through  use  of  the  XFILE  macros  (section  2.3).   Four  files  are  kept  for 
each  user.   When  a  picture  is  sent  from  the  PDP-8,  it  is  immediately 
stored  in  PICLIB.   This  allows  the  user  to  re-analyze  a  picture  at  a 
later  date  without  having  to  re-transmit  it  from  the  PDP-8;  it  is  simply 
retrieved  from  the  file.   After  Item  Analysis  is  complete,  the  output 
data  structure  is  placed  in  ITEMLIB.   There  the  network  can  be  accessed 
as  input  for  Global  Analysis  and  can  be  used  to  translate  internal  code 
names  into  ones  that  the  user  can  identify.   Declarations  of  node  type 
are  written  out  to  NODLIB .   The  last  file  is  ERRLIB  which  contains  all 
the  syntax  errors  detected  by  Item  Analysis. 
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Figure  2.      Monitor  Linkages 


2.2  Input  and  User  Communication 

The  S8  macros  described  in  detail  in  [k]  are  used  for  input 
communication.  A  user  logs  on  to  G80PERAT,  starts  SPACT  and  requests 
that  ITEM  (Item  Analysis)  be  started.  At  this  point  ITEM  executes  an 
S8ENTRY  macro: 

S8EFIRY  N=(2) 

This   notifies   SPACT  that   ITEM  has  begun  executing  and  links 
it   to  SPACT  and  XFILE   (see   Figure  2).       'N=(2)'    means   that   the  work   area 
address   is   in   register  2.      The  macro  S8DATA  is   used  to   set  up  this  work 
area  in  the   correct   format.      Then   an  S8READ  is   executed  which  causes 
ITEM  to  wait  until  a  command  or   a  picture  has  been  sent   from  the  PDP-8. 

S8READ  R=(l),   HALT=HALT 

'R=(l)'    indicates   that   register  1  points   to  the  work   area   and 
will  point  to   the  record  read  upon  return.       'HALT=HALT'    means   that  the 
location    'HALT'    is  branched  to   if  the  user  or  the  system  requests   a  halt. 
This   S8READ  is   executed  every  time   ITEM  requires    action  by  the  user. 
Note   that  upon   completion   of  a   command  or   analysis   of  a  picture,    the 
input  area   (which  is   GETMALN-ed  by  SPACT)    is   FREEMAIN-ed  to  keep  these 
used  areas   from  tying  up   available   core  memory. 

S8WRITE  BUF,TYPE=0,R=(l) ,HALT=HALT 

An  S8WRITE  is   executed  when   a  message   is   to  be   sent  to  the 
user's  terminal.      ITEM  waits   until  the  message   is   transmitted,      BUFF  is 
the  location  of  the  record  to  be  written,    TYPE=0  means   that  0   is 
inserted  into   the  type   field  of  the  record  and  R  and  HALT  are   as    described 
above.      The  following  is   a  list  of  command  messages   to   the  user,   error 
messages   and  their  meaning: 


Command  List 


(ALPHA  is  a  valid  six  character  element  or  network  name) 

1.  'ITEMIZE  ALPHA1— causes  ALPHA  to  be  read  from  PICLIB 
and  put  through  Item  Analysis. 

2.  'ANALYZE  ALPHA' —causes  Item  Analysis  to  call  global 
analysis  with  the  parameter  ALPHA.   Item  analysis 
does  no  processing  of  ALPHA. 

3.  'DESTROY  ERRLIB ' — causes  Item  Analysis  to  delete  the 
user's  error  library.   This  command  is  only  valid  for 
destroying  the  error  library  and  will  not  be 
recognized  if  any  other  file  name  but  ERRLIB  is  used. 

h.      'RESTART  ALPHA' — causes  Item  Analysis  to  call  COG  with 
the  parameter  ALPHA.   The  system  will  restart 
processing  at  that  point. 

5.  'TEST' — allow  diagnostic  blocks  to  be  dumped  on  the  printer. 

6.  'NOTEST' — no  dumps  are  taken.   This  is  the  default  value. 

7.  'LOOP' — set  bit  which  causes  Global  Analysis  to  generate 
loop  equations . 

8.  'NOLOOP' — causes  the  bit  to  be  turned  off  so  no  loop 
equations  are  generated.   This  is  the  default  value. 


Messages  to  User 

1.  'SYNTAX  ERRORS   DETECTED.' 

If  errors   detected  by  Item  Analysis. 

2.  'UNKNOWN    COMMAND.' 

An  illegal  command  was  received. 

3.  'INVALID  BLOCK  TYPE  RECEIVED.' 

An  error  in  transmission  occurred. 
k.       'ITEM  READY  FOR  FIRST  INPUT' 

Indicates  Item  Analysis  is  loaded  and  ready. 

5.  'ITEM  ANALYSIS  COMPLETE' 

The  analysis   of  an  element  is   done   and  Item 
Analysis   is  ready  for  another  input. 

6.  'RECORD  XXXXXX-XXXX  NOT   FOUND.      ENTER  AGAIN.' 
When  an    'ITEMIZE'    command  is   given  and  the 
indicated  block,  does  not  exist  on  PICLIB. 

7.  'MNEMONIC  STORED.' 

After  user  has  sent  a  mnemonic . 

8.  "ERRLIB  GONE... ' 

After  the  'DESTROY  ERRLIB'  command  is  completed. 

Error  Messages 

1.  'NO  :  IN  NODE  TYPE  DECLARATION. NAME  :  E(X,Y)  i    l(P,T9)' 
i.e.,  'ELECTRIC  E(A,B)  ,  l(C,D)' 

2.  'NO  )  IN  NODE  TYPE  DECLARATION. NAME  :  E(X) ,  l(A,R) ' 
i.e.,  'ELECTRIC  :  E(A,B),  l(X' 

3.  'VARIABLES  IN  NODE  TYPE  DECLARATION  NOT  E  OR  I.' 
i.e.  'ELECTRIC  :  W(A,B,C),  Z(Q,R,T)' 


k.       'VARIABLE  REDEFINED. ' 

Variable  defined  twice   as   either  a  global,    local, 
or  parameter. 

5.  'INVALID  ENDING   CHAR   IN  PARAMETER  DEFINITION.' 
Must  end  with  a  single  variable  or   an  equation. 

6.  'NO  E   OR   I   VARIABLES   SPECIFIED  FOR  TYPE.' 
Just    a  type  with  no  variables  was   entered, 
(i.e.,    'ELECTRIC    :') 

7.  'NON-EXISTANT   TERMINAL  TYPE  REFERENCED.' 

When  a  terminal  has  been   assigned  a  type  but   the 
type  was   later   deleted  from  the   list   of  types. 

8.  » *******  ILLEGAL  XXXXXX  DETECTED' 

Message  originates   in  PARSE  and  XXXXXX  refers  to 
the   level  of   compilation  at  which  the  error  was 
detected  in   an   equation. 
All  error  messages   are   also  placed  in  ERRLIB  using  the 
filing  system. 

2.3     Output   Communication 

The  output   from  Item  Analysis   that   remains   in  the   360   is 

[k] 
placed  in  the   filing   system  using  the  XFILE  macros        .      Each   file  name 

is  l6  bytes   long  and  the   convention  used  is    the   first  eight  bytes   of  the 

user's  log-on  name   and  the  second  eight  bytes   are   the   file   name.      For 

example,    all  of  the  pictures   that  JONES   sends  to   ITEM  would  be   stored 

in  the  file  name  . 

i  JiOiNiEiSib^ibiPtl^iLtl.Bjbtb  i 
+0      "  +8  +16 
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Note  that  both  names  are  padded  on  the  right  with  blanks.   Records 
within  a  file  are  named  using  the  first 
record  format  is  as  follows : 


|  RECORD  NAME  I  DATA  LENGTH  (=n)  |   DATA 


+0  +8  +10     +(l0+n) 

The  determination  of  record  names  is  different  for  each  of  the  four 
files  Item  Analysis  uses.   In  PICLIB,  the  six  character  picture  name 
and  a  two  byte  block  identifier  are  used  (section  3).   NODLIB  uses  the 
type  name  (section  k.3)    and  ITEMLIB  uses  the  six  character  picture  name 
with  two  EBCDIC  blanks.   In  ERRLIB,  the  record  names  are  supplied  by 
the  filing  system  so  that  the  last  error  message  appears  at  the  end 
of  the  file. 

Item  Analysis  uses  eleven  types  of  XFILE  macros.   To  use  the 
system,  a  location  called  'ABEND'  is  provided  which  causes  ITEM  to 
terminate  abnormally.   This  location  is  branched  to  by  the  XFILE  macros 
when  an  error  is  detected  by  the  filing  system  (e.g.,  'record  not 
found',  'file  not  open  on  attempted  read'). 

<name>  XLIST  NAME=XXXXXXXX<name>  , 
NREC=1 

The  XLIST  macro  creates  an  area  where  parameters  and  status  and 
control  codes  for  each  file  are  stored.   There  is  an  XLIST  for  each  of 
the  four  files  used  by  ITEM.   When  doing  a  filing  system  operation,  values 
are  stored  in  the  XLIST  and  then  the  call  to  XFILE  is  made.   Therefore,  only 
the  parameters  that  were  changed  from  the  last  call  need  be  specified. 
For  example,  since  the  number  of  records  read  or  written  at  a  time  is 
always  one  in  ITEM,  the  value  NREOl  only  appears  on  the  XLIST  macro 
and  not  with  each  separate  read  or  write. 
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XINIT  ITEMLIB 

This  macro  causes  the  filing  system  to  be  initialized.   This 
allows  the  user  to  access  the  file  defined  by  the  control  card: 

//DISK  DD  DSN=xxxxxxxx,DISP=OLD 
The  ITEMLIB  XLIST  is  used  as  a  scratch  area.  When  control  is  returned 
to  ITEM,  Rl  points  to  the  XDSCB,  an  internal  control  block.   All  four 
parameter  lists  that  are  going  to  be  used  must  be  linked  together  using 
the  f olloiwng  macro : 

rXDSCB=(Rl)   , 

The  XDSCB  parameter  is  supplied  in  the  first  XLINK  since  the  pointer 
is  in  Rl  upon  return  from  the  XINIT.   The  LIST2  parameter  is  then  used 
in  the  three  other  XLINK's  to  link  the  parameter  areas  together. 

XOPEN  <name> 

All  files  that  are  to  be  read  from  or  -written  to  must  first 
be  opened.   The  above  macro  is  used  to  open  each  file  before  any  I/O 
is  performed  on  them. 

XDELETE  PICLIB,BUF=(1)  ,TEST=(-i,RNF) 

Upon  receiving  a  picture  (through  an  S8READ) ,  Item  Analysis 
does  an  XDELETE  on  PICLIB  to  delete  that  record  if  it  has  previously  been 
sent.  BUF=(l)  means  that  the  record  address  is  in  register  1  (the  first 
eight  bytes  to  the  record  name).   TEST~(-i  ,RNF)  ensures  that  the  system  will 
not  abend  if  the  record  not  found  condition  occurs.   If  this  macro  was 
not  executed,  a  subsequent  attempt  to  write  the  same  record  onto  PICLIB 
would  result  in  an  abnormal  termination. 
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XREAD  PICLIB,BUF^(10)  ,BUFU1N=(T)  ,TEST=(NOGO,RNF) 

This  causes  a  picture  previously  sent  to  the  360  to  be  read 
from  PICLIB.   The  parameters  BUF=(lO)  and  BUFLEN=(7)  indicate  the 
registers  where  the  address  of  the  buffer  and  its  length  are  to  be  found. 
TEST=(N0GO,RNF)  causes  ITEM  to  branch  to  the  location  'NOGO'  when  the 
record  not  found  condition  occurs.   Thus,  the  user  has  requested  a 
picture  that  has  not  been  stored  on  PICLIB  (#6  in  "Messages  to  User'). 

XWRITE  <name>,BUF=(lO),BUFLEN=(7) 

When  any  records  are  to  be  written  on  PICLIB,  NODLIB  or 
ITEMLIB,  the  above  macro  is  used.   BUF=(lO)  and  BUFLEN=(T)  indicate 
the  registers  where  the  address  of  the  record  to  be  written  and  the 
buffer  length  are  located.   (Note  that  BUFLEN  is  10  more  than  the  value 
found  at  BUF+8). 

XAPPEND  ERRLIB ,BUF= ( R6 ) ,BUFLEN= ( R2 ) 

The  syntax  errors  detected  are  written  onto  ERRLIB  with  the 
above  macro.   The  name  is  supplied  by  the  system  but  eight  bytes  for  the 
name  must  still  appear  at  the  beginning  of  the  message.   The  parameters 
are  the  same  as  in  an  XWRITE. 

XCLOSE  <name>,TEST=H,SEQ) 

All  the  files  are  closed  before  ITEM  is  exited.   TEST=H,SEQ) 
means  that  the  system  will  not  abnormal  end  if  the  file  appears  to 
be  closed  already. 

XDESTROY  ERRLIB 

This  macro  is  used  when  the  user  has  examined  his  error 
messages  and  wishes  to  get  rid  of  the  entire  error  message  file  (#3  in 
'Command  List').   This  macro  is  executed  with  ERRLIB  properly  linked 
but  not  opened. 
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XTERM  ITEMLIB 

This  is  the  last  call  issued  to  the  filing  system  and  does 
all  of  the  required  processing  to  terminate  use  of  the  filing  system. 
ITEMLIB  is  once  again  used  as  a  scratch  area. 


Ik 


3.   INITIALIZATION  AND  INPUT  SPECIFICATIONS 


Item  Analysis  must  be  initialized  when  it  is  first  called 
because  of  the  use  of  the  S8  and  XFILE  macros  for  Input/Output.  Work 
areas  for  these  macros  are  set  up  and  linked  together.   The  user's 
log-on  name  is  moved  into  the  four  XLISTs  from  the  SPACT  parameter  list 
(Figure  3).   These  will  be  used  as  file  keys  (see  section  2.3).   ITEM 
is  now  ready  to  accept  commands,  pictures  or  mnemonics  from  the  user. 
Note  that  ITEM  is  waiting  for  a  user  response  after  issuing  an  S8READ 
whenever  it  is  not  processing. 


SPACT 


Parmlist   for   subtask 

+0    (available) 

+k  A(user  work  area] 

+8  A(XFILEOOl) 
+12  A(log  user) 
+l6  A(parm  string) 


Subtask 

(user  must : 

1.  save  parmlist   address 

2.  set  XFILE001   into  V-con 

3.  call  S8ENTRY 
before   anything  else) 


Parmstring 

2U   characters : 
parm  field 
(from  START   command) 


Loguser 

8  characters : 
user  logon  name 


Trmcntrl 

+0  2TO10PRQ:    READ  request  ECB 

+h  WRITE  request  ECB 

+8  A(user  work  area)   +8  0Pdone  ECB's 


User  Work  Area    (lU  words) 

+0   0  SPACT  ECB   for 

HALT  request 
+k  A(2TO10PRQ)      2701  request   link 
+8   0  2701  Read  done  ECB 

+12   0  2701  Write   done  ECB 

+16    (+8,+12,+0)      S8WAIT  ECBLIST 
+28    (+8,+0)  S8READ  ECBLIST 

S8WRITE  ECBLIST 
A (OTHER) 

Register  2   save  wrd 
Addressability 
save  word 


+36  (+12, +0) 
+hk   0 
+U8  0 
+52  0 


Figure  3.   SPACT/User-Program  Linkage  After  S8ENTRY 
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When  data  is  sent  to  the  360  from  the  PDP-8,  the  six  bit 
PDP-8  byte  is  right  justified  in  the  eight  bit  360  byte.   The  first  two 
bits  are  zero.   For  characters,  a  simple  translate  from  ASCII  to  EBCDIC 
is  all  that  is  needed;  but  for  numbers,  the  bits  must  be  shifted  to 
eliminate  the  extra  zero  bits  that  were  inserted.   The  macro  LDP  is 
used  in  ITEM  to  shift  two  bytes  around  and  end  up  with  the 
correct  number. 

Bytes  6  and  7  of  data  sent  to  the  360  are  checked  for  the 
type  of  block.   If  byte  6=0,  the  block  is  a  command  from  the  user.   If 
non-zero,  then  it's  a  mnemonic  if  byte  7  is  also  non-zero.   Otherwise, 
it  is  the  header  block  for  a  picture.   Each  picture  is  composed  of  a 
header  and  10  other  blocks.   Each  block  has  a  code  in  bytes  6  and  7 
which  is  used  as  the  last  two  bytes  of  the  record  key  when  it  is 
written  onto  PICLIB  (e.g.,  the  header  for  GRVLRK  would  be  in  PICLIB 
under  the  record  name  'jG  ,R|Vr  L,  N  j  K ,  8 1 0t'  ).   The  codes  for  each  block 
are  as  follows : 


Code  (2  bytes) 

0800 

0801 

0802 

0803 

080^ 

0805 

0806 

0807 


0809 
080A 


Block  Type 

Header 

Local  lines 

Comment  text 

Subpictures 

Spare  block 

Terminal  connections 

Declarations 

Equations  and  parameters 

Spare  blocks 
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The  macro  PDP8DATA  contains  DSECTs  which  describe  the 
relative  position  of  individual  fields  within  the  input  blocks. 

3.1  Header  Block 

The  header  block  (Figure  k)    contains  bits  that  indicate 
if  a  block  exists.   If  it  does  not  exist,  no  attempt  is  made  by  ITEM 
to  read  it.   Even  though  ITEM  does  not  use  the  local  lines  or  comment 
text  blocks,  these  are  placed  on  PICLIB  so  the  user  may  retrieve  a 
picture  from  the  360  and  have  all  the  blocks  necessary  to  construct  it 
on  the  screen.   Thus,  the  header  block  is  used  to  allocate  space  for 
reading  the  rest  of  the  blocks. 


=  unused  byte 


* 

A 

1  1  1  &\ 

1 

} 


length  of  GETMAINed  area 

Console  number 

Header   code    ( '0800' ) 

Length  of  the   following   (in  words): 

Name   of  picture 

Total  length  of  data   (in  blocks) 

PDP-8   address 

Control  check  word 

User  identification 

The  following  halfwords  are  (length  of 
blocks )/256.   If  bit  1=1,  no  block  exists 

Local  line  block  length 

Comment  text  block  length 

Subpicture  block  length 

Spare 

Node  connection  block  length 

Declaration  block  length 

Equation  block  length 

Spares 


Figure   4.      Header  Block   Layout 
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3.2  Subpicture  Block 

The   subpicture  block   (Figure   5)    contains   three  sub-blocks 
for  every  instance    (occurrence)    of  an  element   in  a  network.      The   first 
sub-block  contains   the  name  of  the  element  and  its   sequence  number 
(e.g.,    the   first  element  put  into  the  network   is    #0 ,   the  second  is    #1 , 
etc.).      ITEM  uses   this  block   to   create   the   Element  Instance  table 
(section   h.'j) .      The  second  sub-block   contains   the  parameter   assignments 
for  an  instance.      The   third  sub-block  holds    a  list   of  the  types   of 
terminals   on  that   subpicture.      If  there   are   two   or  more  terminals    of 
the  same  type   on  an  element,   the   type  name   appears   only  once   in   this 
list   and  the  terminals    reference   its   position   in  the  list    (e.g.,    if 
there   are  two   CONTROL  terminals,   the  name    'CONTROL'    appears   once   in 
the   list,   say  in  position  3 — then  those   terminals   reference  position   3). 

3.3  Terminal  Connection  Block 

The  terminal  connection  block  (Figure  6)  contains  a 
description  of  all  the  terminals  in  a  picture  and  their  interconnections. 
Entry  1  has  the  names  of  all  the  types  of  local  (not  assigned  to  an 
instance)  terminals.   Entry  2  has  the  connections  from  terminal  NX  to 
terminal  MX.   This  entry  is  used  by  ITEM  to  construct  the  Node/Connection 
Table  (section  h.j).      Finally,  every  terminal  in  the  picture  is  described 
in  the  remaining  entries. 


□  S  byte 
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Disp  =  (#  bytes  to  next  subpicture)/2 
Sub-block  1 :   Name  and  Number 


Name  of  subpicture  (6  characters  followed  by  two  blanks) 


]...□ 


Y  coordinate   of  subpicture 

X  coordinate 

Sequence  number  of  this    subpicture    (0   to  n) 
Sub-block  2:      Parameters 

User  identification 

Disp  =    {#  bytes   in  parm  sub-block) /2 

Y  coordinate   of  text 

X  coordinate 
Containing   text   lines   of  the   form: 

Count  =   (#   characters  in  text)/2  =  P 

Text   line  of  parameters 


P   characters 
"^-•Next   line   of  parameters 

Sub-block   3:      Node  Type  Names 


C 


Disp  =    (#  bytes   in  node   type  name   sub-block )/2 

Y   coordinate   of  text 

X  coordinate 
Containing  text   lines   of  the   form: 

Disp  =(#   of  bytes   in  node   type  name   text)/2  =   R 


]...□ 


R  characters 
^-♦Next  node  type  name 
Next  subpicture 


Figure  5.   Subpicture  Block 
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□  -   byte 


Disp  =    {ti  bytes   in   terminal   connections  block)/? 
Entry    1:      Type   Name   List    for  Local   Terminals 

H     I    I  Disp  =    (#  bytes   in  entry  l)/2 

| Y   coordinate 

X  coordinate 
Containing  text   lines   of  the  form: 

Disp  =   (#   characters   in   line)/2  =  S 

Local  terminal  type  name 


S   characters 
•Next  terminal  type  name 
»Entry  2 :      Terminal  Connection   List 


Disp  =    (#  bytes   in  entry  2)/2 


VJNll  From  terminal  Nl 

V  =  1   (first  bit)   visible   connection 

V  =  0  invisible   connection 

1 0  |Ml|  To  terminal  Ml 

|VtNXJ  From  terminal  NX 

|0|MX|                                   To   terminal  MX 
»•  Entry  3  •      First  Terminal 


~^\  Disp  =   (#  bytes   in  entry  3)/2 


|AB|     I  Instance   sequence  number  to  which  this  terminal 

belongs.      A,B   are  the  first   two  bits: 
A  =  1  local  terminal 

A  =  0  terminal  belongs   to  a  subpicture   instance 
B  =   1  external   terminal   (A  =   l) 
B  =  0   internal  terminal 


Identification  number  of  this   terminal 


I     I     I  Terminal  type  name  number 

C   (first  bit)   =  0,   type   assigned 
C  =  1,  type  unassigned 

I     1     1  Y   coordinate   of  terminal 


X   coordinate 

^Entry  k:      Second  Terminal 


Same    as   entry   3 


— *"£nd 
Figure  6.   Terminal  Connection  Block 
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3.1*      Declaration   Dlivk 

Tlie   declaration  block  has  the   form  of  a  text  block    (Figure   7) 
with  three   entries.      The   first   contains   declarations  of  the  E-  and 
I-type  variables   associated  with  terminal   types    (see   section   U.3).      The 
second  has  the  list  of  global  variables   and  the  third  has   the  local 
variables    (section  U.U). 


□  =  byte 


Disp  =     (#  bytes   in  block  +l)/2 
Followed  by  text  entries   of  the   form: 

Disp   =   (#  bytes   in  this   entry )/2 
Y   coordinate 
X   coordinate 

Containing  text   lines   of  the   form: 

Count  =    (#   characters   in   following  text   line)/2 
Text   line 


=  Q 


Q  characters 
"Next  line  in  this  entry 


•Next  text  entry 


-•END  of  text  block 


Figure  7.   Text  Block 


3. 5  Equation  and  Parameter  Block 

The  last  block  is  also  a  text  block  but  with  two  entries 
(Figure  7)-   The  parameters  are  listed  in  entry  one  and  are  used  by  ITEM 
to  generate  the  list  of  parameters  and  default  equations  (section  U.5). 
Entry  two  has  all  the  equations  associated  with  the  whole  network.   These 
are  parsed  by  ITEM  and  their  coded  binary  tree  representation  is  placed 
in  the  output  structure  (sections  k.l,    U.2). 


PI 

k.      OUTPUT  DATA  STRUCTURES 

Item  Analysis  is  designed  to  translate  certain  data  into  a 
representation  suitable  for  Global  Analysis.   These  tables  are  placed 
on  the  filing  system  for  use  in  communication  between  the  user  and  the 
system.   The  items  that  are  just  translated  and  checked  for  syntactic 
errors  are  the  user  definition  of  terminal  types,  global  variables, 
local  variables  and  parameters.   As  shown  in  Figure  8,  the  lists  of 
eight  character  (byte)  names  of  globals ,  parameters,  locals,  double 
precision  constants,  left  hand  and  EI  type  variables  are  referenced  by 
counters  and  pointers  at  the  topmost  level  of  the  output  structure. 
Equations  are  handled  both  for  the  entire  picture  and  for  each  element 
within  that  picture.   The  network  is  broken  down  into  the  pointers  and 
tables  shown  in  Figure  10.   Each  element  becomes  an  entry  in  the 
Element  Instance  table.   Finally,  the  whole  structure  is  assembled 
and  written  onto  ITEMLIB  under  the  picture  name . 

h.l     Equations 

All  equations  are  parsed  into  a  tree  structure  in  a  separate 
routine  called  PARSE.   A  top-down  parse  was  used  because  of  the  relative 
ease  of  programming,  debugging  and  modifying.   Also,  this  method  allowed 
us  to  isolate  certain  special  case  equations  for  special  handling 
(section  U.2) . 

The  top  level  consists  of  a  string  of  pointers  linking  all  the 
equations  of  a  certain  type  together  (default,  network,  parameter  or 
element  equations).   The  first  word  in  each  equation  contains  the  length 
of  the  equation  (i.e.,  displacement  to  the  next  equation)  or  '0' 


□  S  byte 

♦ol 
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+12 
+3.1* 

+16 
+18 
+20 
+22 
+2k 
+26 
+28 


ED 


+30 
+32 
+3U 
+36 
+38 

+ko 

+1+2 

+kk 
0U6 

#1*8 
#50 
#52  f 


#6oD...D 


length  of  GETMAIN   =   X'000020001 

picture  name — 6  characters  and  two 
EBCDIC  blanks 

length  of  remaining  structure  (in  bytes) 

Disp  to  the  network  (Figure  10)  (NETP) 

Disp  to  equations 

length  of  equations 

Disp  to  default  equations 

length  of  default  equations 

#  of  entries  in  terminal  type  list 
Disp  to  terminal  type  list 

#  of  global  variables 
Disp  to  list  of  globals 

#  of  parameters 

Disp  to  list  of  parameter  names 

#  of  local  variables 

Disp  to   local  variable   list 

#  of  double  precision  constants 
Disp  to  constant  list 

#  of  left-hand-side  variables 

Disp  to  list  of  left-hand  variables 

#  of  E-  and  I-type  variables 
Disp   to  EI  list 

Name   of  element 


All   lists ,    equation   trees   and 
network   definition 


All   displacements   are   from  +0 

Figure   8.      Output   Data  Structure 
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indicating  this  is  the  last  equation  in  this  chain.   The  first  two  bits 
of  the  second  word  are  used  to  indicate  the  equation  type: 

00 — element  equation  "\  resolved  in 

01 — network  equation  )     Global  Analysis 

10 — default  equation   "\  resolved  in 

11 — parameter  equation^  Item  Analysis 
The  remainder  of  the  first  two  bytes  of  the  second  word  is  the  equation 
number  in  the  indicated  block.   The  last  two  bytes  are  used  by  Global 
Analysis  for  the  displacement  from  the  top  of  the  interval  tree  to  the 
entry  associated  with  this  equation's  element.   The  rest  of  the  words 
contain  the  equation  in  tree  form.   Each  node  of  the  tree  consists  of 
two  or  three  halfwords. 

i  0  1  L|  R  | 


1  0  1  L  1 

Where   0   is   the   operation  or  operand  and  R,    L  are   the   right   and  left 
operands,   respectively.      As   an  operand,   two  halfwords   are  used;   L 
indicates  the  number  of  the  element   in   the  indicated  list.      0   can  be 
one   of  the  following: 

X' 01'  —Global  variable 

X'021 — Parameter  or  left-hand  variable 

X'03' — Local  variable 

X'OV — E  or  I-type  variable 

X'06' — Double-precision   constant 
As   an  operation,   R  and  L  are   displacements   from  the  beginning  of  the 
equation  to  the   operands.      The   legal   codes   for  0   are 


2k 

X' 07 '--Equal  sign 

X' 08' --Addition 

X'  09'—  Subtraction 

X'OA1— Multiplication 

X' OB '--Division 

X'OC  — Assignment 

X ' OD ' — Exponenti  ation 

X '  10  '  —Differentiation 

X'll' — Unary  minus 
Differentiation  and  unary  minus  are  two  while  the  others  are  three 
halfwords  long.   Special  operators  are 

X' 12 '—System  function 

X'13' — User  function 
For  the  system  function,  the  L  halfword  contains  one  of  the  following  codes. 

X'01' — Natural  logarithm — LOG 

X'02' — Exponentiation  (natural  base,  e,  raised  to  a  power) — EXP 

X' 03 '—Square  root— SQRT 

X ' 0 V  — Arctangent — ATAN 

X' 05'— Absolute  value — ABS 

X'06'— Cosine— COS 

X'  07  '—Sine — SIN 

L  in  the  user  function  contains  a  count  of  the  number  of 
operands  needed  (say  N)  ,  followed  by  N  halfwords  which  contain  displacements 
to  the  operands.   All  blanks  in  the  equations  are  ignored.   The  first 
operation  (root  of  the  tree)  is  the  equal  sign  which  begins  in  the  third 
word  of  the  equation. 
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U.2  Parsing  Equations 

The  parsing  routine,  PARSE,  is  set  up  as  a  subroutine  called 
by  Item  Analysis.   This  was  done  since  it  is  possible  for  equations  to 
be  present  in  several  places  in  the  input  structure.  When  PARSE  is 
called,  register  1  points  to  the  list  of  parameters  depicted  in 
Figure  9-   PADDR  points  to  the  equation  to  be  parsed. 

Since  PARSE  works  in  a  top-down  manner,  the  error  messages 
returned  to  the  user  are  general  ones.   For  example,  "******ILLEGAL  IDENT 
DETECTED"  would  refer  to  a  specific  equation  but  not  to  a  specific 
identifier  within  that  equation. 

PARSE  uses  a  register  stack  to  allow  it  to  make  a  guess  and 
then  easily  backtrack  if  that  guess  was  incorrect.   Each  type  of 
statement  has  a  separate  routine  that  stores  registers  and  updates  the 
stack  pointer  on  entry.   Registers  1  and  10  are  used  to  point  at  the 
current  position  in  the  equation.   When  an  incorrect  guess  is  made,  the 
calling  routine's  registers  are  restored,  thus  moving  the  pointers  back. 
When  a  successful  guess  is  completed,  all  registers  but  1  and  10  are 
restored.   If  an  error  is  found,  a  message  is  printed  and  put  on  ERRLIB 
and  a  successful  exit  is  made  (not  restoring  registers  1  and  10).   This 
was  done  to  cause  PARSE  to  skip  over  the  bad  areas  in  an  equation  and 
to  catch  other  errors  in  the  remainder  of  the  equation  if  they  exist. 

Equations  are  parsed  in  the  normal  fashion  until  the  special 
cases  of  LOG  or  SQRT  are  discovered.   These  functions  have  caused 
problems  since  they  have  points  of  singularity  and  complex  results. 
When  searching  for  an  initial  steady  state,  the  "random"  initial  values 
used  could  cause  these  functions  to  cross  these  points  of  singularity 
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and  abort   the   system.      For  each  occurrence   of  LOG  and  SQRT,   an  extra 
variable   and  equation   are   generated. 
User's   equation 


Output   equations 
A  =   KOTCH001  +   C 
KOTCH001*KOTCH001  =   B 
L  =  M*KOTCH002 
EXP(KOTCH002)    =  N 
X  =   KOTCH003/Z 
EXP(KOTCH003)    =   KOTCH00H 
KOTCH00U*KOTCH00U  =   Y 
Then   it   is  possible   to   constrain   these  variables   to  be  initially  positive 
The  Backus  Normal  Form  description   of  the  parse  used  is   in  the  Appendix. 


A  =  SQRT(B)  +  C 


L  =  M*LOG(N) 


X  =  LOG(SQRT(Y))/Z 


PARSPARM 

DS 

OF 

DS 

X 

PADDR 

DS 

AL3 

PEND 

DS 

A 

VLOC 

DS 

A 

VGLB 

DS 

A 

VPAR 

DS 

A 

VEI 

DS 

A 

VLH 

DS 

A 

VCON 

DS 

A 

FRES 

DS 

A 

LASTEQN 

DS 

A 

COUNT 

DS 

A 

S8W0RK 

DS 

A 

ERRLIST 
* 

DS 

A 

VLHBIT 

EQU 

X'80' 

HALTBIT 

EQU 

X'UO1 

ERRBIT 

EQU 

X'20' 

MOREQN 

EQU 

X'08' 

EXTRAS 

EQU 

X'OV 

PFLG 

DS 

X 

TRANS 

DS 

AL3 

FILE 

DS 

A 

PTR 

DS 

A 

END 

DS 

A 

Figure 
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ADDR  OF  WHAT  I  AM  TO  SCAN. 

END  OF  WHAT  TO  SCAN. 

LOC  OF  LOCAL  VARIABLES. 

GLOBAL . 

PARAMETERS . 

E/I  NAMES. 

LH  SIDE  VARIABLES. 

CONSTANTS . 

WHERE  TO  GET  FREE  SPACE. 

ZERO  WHEN  STARTING  NEW  EQN  TREES. 

EQN  NUMBER  IN  BLOCK. 

ADDR  OF  WORK  AREA  FOR  MESS.   TO  PDP8. 

ADDR  OF  ERRLIB  DCB  FOR  PARSE  ERRORS. 

POSSIBLE  FLAG  BITS: 

ONLY  1  VARIABLE  ON  LEFT  SIDE  OF  = 

ON  IF  PARSE  HALTED. 

ON  IF  ERRORS  DETECTED  BY  PARSE. 

ON  IF  MORE  EQNS  GENERATED  BY  PARSE. 

ON  IF  PARSING  THOSE  EXTRA  EQNS. 

WHERE  THE  ABOVE  FLAGS  ARE  TURNED  ON. 

ADDR  OF  EBCDIC  TO  ASCII  TRANS.   TABLE 

ADDR  USED  BY  XAPPEND  IN  PARSE 

ADDR  OF  1ST  AVAIL  POS  FOR  EXTRA  EQNS 

ADDR  OF  END  OF  ABOVE  AREA 

Parameters  for  PARSE 
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k. 3     User  Terminal  Type  Names 

The  simulation   system  allows  the   user  to  pass   variables    from 
terminal  to   terminal  through  the  use  of  E-  and  I-type  variables.      E- 
and  I-type  variables   are   those   that  obey  Kirchoff's  voltage   and  current 
laws,   respectively,   and  they  refer  to  terminals  by  using  the  terminal 
number  as   a  subscript    (e.g.,    VOLT(l),   V0LT(3),    CURKENT(T)).      To   ensure 
that  the  correct  variables   are  passed,   only  terminals   of  the  same   type 
may  be   joined.      The  user  declares   a  terminal  type  with  the   following  syntax, 
terminal  type  name    :E(    E-type  variables    ) , 

l(    I-type   variables    ) 
For  example,    an  electrical  terminal  might  be    declared  as    follows: 

ELECTRIC:    E(VOLT,    X) ,    l(CURR,    Y) 
Then  each  ELECTRIC  terminal  would  have   two  E-type    (VOLT  and  X)    and  two 
I-type    ( CURR  and  Y)    variables   associated  with   it.      Item  Analysis  takes 
the  terminal  type   declarations   and  writes   them  onto  NODLIB.      There   they 
can  be    accessed  by  Global  Analysis  to   determine   if  the  E-   and  I-type 
variables    in  the   equations  refer  to  the   correct  terminals.      Item  also 
uses   the  user   assigned  terminal  type  names   in   the  Node-Connection  table 
(section  U.7) . 

h.h     Global   and  Local  Variables 

Global  variables   are   those   that   are   associated  with  a  whole 
element  rather  than   a  terminal.      These  variables   are   accessible  by  the 
network  and  have   the   same  value   for  all  elements  at   a  particular  level  in 
a  network.      Local  variables   are   those  that  are   also   associated  with  the 
whole  element  but   are  not   accessible   from  the  network.      The  user    can 
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either  enter  globals   and  locals  one   to   a  line   or  more   than   one   to   a  line 
separated  by  commas. 
ALPHA 

BETA  or  ALPHA , BETA , GARBAGE 

GARBAGE 
Also  note  that  any  variables  not  assigned  a  type    (global,   local,    special 
or  parameter)   will  end  up   as  local  variables.      Item  Analysis  prepares   a 
list  of  the  names   of  global   and  local  variables   and  a  count   of  each  and 
places   them  in  the  output   data  structure    (Figure   8). 

h. 5     Parameters 

Parameters   are   those  variables  that   can  have   a  different  value 
for  each  instance    (occurrence)   of  an  element    (e.g.,   resistance,  weight). 
Since   a  value  must  be   specified  for  each  occurrence   of  an  element,   the 
user  is   allowed  to  assign   a  default   value   to   a  parameter.      Thus,    if  a 
resistor  with   a  default   resistance   of  100   is   used  in   a  network  and  no 
new  resistance   is   specified,    its   resistance  will  remain   100.      Parameters 
are  entered  in  the   same  manner   as   globals   and  locals  but  may  have   default 
values   associated  with  them.      The   following   are   legal  parameter 
declarations . 

REST,TEMP=30.T5VAR 

ORANGE 

M0NK=T63+GVAR 
A  list  and  count   of  parameters   is  made  by  Item  Analysis   and  it  must   also 
check  for  default  equations.      When   a  default   equation   is    found,    it  must 
have   only  one  variable   on  the  left   side   of  the   equal  sign.      It  is  parsed 


29 

by  Item  (section   U.l,    U.2)   and  its  binary  tree  representation  placed 
in  the  default  equations   section  of  that  element    (Figure   8). 

k.6     Left-hand-side   Variables 

Left -hand- side  variables   occur  only   in   the  default  equations. 
Any  variable  occurring  on  the  "left-hand-side"  of  a  default  equation  will 
be  put   in   this   list.      This    causes   the  variable   to  be  assigned  the  value 
occurring  on  the   right-hand-side   during  the   simulation.      Otherwise,   the 
variable's   value  would  be   allowed  to   change  when  the  system  tried  to 
"balance"  the  values   on  both  sides   of  the  equal  sign.      Thus,   the  equal 
sign   is   changed  to   an   assignment  operator. 

U.7     Network  Output 

A  set  of  pointers   and  tables   that   completely  describe   the 
structure   of  the  network  is  pointed  to  by  NETP    (Figure   8).      If  the 
picture   analyzed  is   a  basic  element,  NETP  =   0   and  these  pointers    do 
not  exist   in  the  output   structure.      Item  Analysis   receives   as   input   a 
list  of  connections    (e.g.,    0-9,   1-8,   9-7,    5-7,    8-6,   2-h)    and  the 
correspondence  between  terminals   and  elements.      ITEM  resolves  these 
into  a  Node/Connection  table. 
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**  All  displacements  in  this  section  are  from  +0, 

Figure  10.   Network  Output 
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A  node  in  this  context  is  composed  of  a  group  of  terminals  that  are 
interconnected.   For  instance,  in  Figure  11,  there  is  a  node  composed 
of  terminals  0,  9>  T»  5  and  one  of  1,  8,  6  and  a  third  of  2,  h.      So 
there  are  three  entries  in  the  node  part  of  the  table  and  NNODES  =  3. 
Linked  to  each  entry  in  the  node  portion  are  the  rest  of  the  terminals 
that  are  interconnected.   In  the  example,  NEXT  contains  the  position 
number  in  the  table  of  the  next  terminal  that  is  on  this  node.   If 
NEXT  =0,  it  is  the  last  terminal  in  the  chain.   USERS  are  the  original 
terminal  numbers  assigned  when  the  user  originally  drew  the  picture. 
The  first  field  of  the  terminals  in  the  node  part  of  the  table  is  an 
eight  character  name  of  the  terminal  type  assigned  to  this  node. 
Global  Analysis  checks  to  see  that  all  terminals  on  a  node  are  of  the 
same  type.   The  first  field  in  the  connection  part  of  the  table  is  a 
position  number  referring  back  up  to  the  node  to  which  this  terminal 
is  connected.   Thus,  in  the  example,  position  k   in  the  table  (originally 
terminal  #7)  is  connected  to  node  0.   The  remaining  two  fields  in  the 
connection  part  are  the  same  as  in  the  node  part.   For  the  example, 
NCONNS  =  6  since  there  are  six  entries  in  the  connection  part  of  the 
table.   The  position  numbers  in  the  Node/Connection  table  are  used 
later  when  a  list  of  the  terminals  on  each  element  is  constructed.   This 
was  done  to  facilitate  a  search  by  Global  Analysis  through  the  network. 

Item  Analysis  also  constructs  an  Element  Instance  table 
(Figure  12).   This  is  a  list  of  all  the  elements  that  were  used  to 
construct  the  network.   Each  entry  in  the  table  consists  of  an  eight 
character  element  name  and  four  halfwords.   The  halfwords  indicate  the 
length  of  the  assigned  parameter  equations  and  their  position  and  the 
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number  of  terminals  on  the  element  and  a  displacement  to  a  list  of  them, 
respectively.   Each  element  was  given  a  separate  parameter  block  because 
of  the  possibility  of  two  elements  of  the  same  type  being  used;  for 
instance,  if  two  resistors  were  used  but  in  the  first  instance  the 
parameter  resistance  was  assigned  a  value  of  100  while  in  the  second 
instance  it  had  a  value  of  200.   In  this  manner,  the  two  parameter  blocks 
can  be  distinguished. 

The  next  two  halfwords  in  the  network  output  section  (Figure  10) 
are  the  length  of  and  displacement  to  the  network  equation  tree.   These 
refer  to  the  equations  that  were  written  that  reference  the  entire 
network.   Finally,  there  is  a  list  of  the  position  numbers  in  the 
Node/ Connection  table  of  all  external  terminals. 


TTTTTT 


Element  name 


Length  of  the  parameter  equations 
associated  with  this  element 


Disp  from  network  base  (+0  Figure  10) 
to  parameter  equations 

#  of  terminals  on  element 


Disp  from  network  base  to  list  of 
position  numbers  in  Node /Connect ion 
table  corresponding  to  the  terminals 
on  element 


Figure  12.   Element  Instance  Table  Entry 
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DEFINITION  OF  PARSE 

<ASSIGN>    : :=   <IDENT>    =   <EXP> 

<EXP>    ::=   <TERM>    <EXP  FRAG> 

<EXP  FRAG>    ::=   <PTERM>    <EXP  FRAG>  |  <MTERM>    <EXP  FRAG>  |  <NULL> 

<NULL>    :  :  = 

<TERM>    ::=   <FACTOR>    <FACTOR  FRAG> 

<FACTOR  FRAG>    : :=   <MULFACTOR>    <FACTOR  FRAG> | <DIVFACTOR>    <FACTOR   FRAG> | <NULL> 

<PTERM>    :  :=  +<TERM> 

<MTERM>    :  :=  -<TERM> 

<FACTOR>    ::=   <DIFFER>    <AFACT> | <DIFFER> 

<PRNEXP>    : :=    (<EXP>) 

<AFACT>    : :=   **<FACTOR> 

<DIVFACTOR>    : :=    /<FACTOR> 

<MULFACTOR>    : :=   *<FACTOR> 

<DIFFER>    :  :=   <POWER>  "  '  ' *  | 

<POWER>  '"I 

<POWER> ' '     | 

<POWER> '       | 

<POWER> 
<POWER>    :  :=   <ICON>  |  +<ICON>  |  -<ICON>  |  <PRNEXP>  |  -<PRNEXP>  |  +<PRNEXP> 
<ICON>    ::=   <IDENT>  |  < CONSTANTS > 
<SUBSCRIPT>    : :=    ( <NUMBER><NUMBER> . . . <NUMBER> ) 
<NUMBER>    :  :=   0|l|2|3|U|  5|6|7|  8|9 
<LETTER>    :  :=  A|B|C|D|  .  ..|W|X|Y|  Z 
<ALPHANUM>    :  :=   <LETTER>  I  <NUMBER> 
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<CONSTANTS>    : :=    <NUMBER> . . .<NUMBER>   E   <NUMBER><NUMBER> | 
<NUMBER> . . . <NUMBER>    D   <NUMBER><NUMBER> | 
<NUMBER> . . . <NUMBER> 
<^IDENT>    :  :=  MAX   (  <EXP>  ,    <EXP>  , .  .  .  ,    <EXP>)|MIN    (  <EXP>  , .  .  .  ,    <EXP>)| 
SIN    (<EXP>)|COS    (<EXP>)|ABS    ( <EXP> ) 
ATAN    (<EXP>)|SQRT   (<EXP>)*|EXP    ( <EXP> ) | 

LOG   (<EXP>)*|  <LETTER>    FOLLOWED  BY   FROM  0   TO   7    <ALPHANUM> » s 
<SUBSCRIPT>|<LETTER>    FOLLOWED  BY   FROM  0   TO   7    <ALPHANUM> ' s 


*      'LOG'    and   'SQRT'    are   special  cases    (see   section  k.2) 
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